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(54) Protected keep alive message through the internet 



(57) A method and apparatus for determining the 
reachability of a remote computer from a local computer 
through a secured communications link through the In- 
ternet. In one embodiment, the secured ISAKMP/Oak- 
ley communications link is established between a re- 
mote computer and a local computer through the Inter- 
net. A protected keepalive message is transmitted by 
the local computer to the remote computer in the event 
that the communications link has been idle for a period 
of time. The protected keepalive message is not a re- 
key request by the local computer to renegotiate the pol- 
icy/key(s) of the secured communications link to the In- 



ternet. In one embodiment, the protected keepalive 
message is a protected ISAKMP/Oakley command to 
which a protected acknowledgement must be supplied. 
If a protected acknowledgement is received from the re- 
mote box by the local box in response to the protected 
keepalive message, then it is assumed that the remote 
box is still reachable. However, if the protected acknowl- 
edgement is not received from the remote box in re- 
sponse to the protected keepalive message, then it is 
assumed that their remote box is no longer reachable. 
In this case, the secured communications link between 
the remote box and the local box is terminated by the 
local box. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0001] The present invention relates generally to the 
field of data communications and, more specifically, the 
present invention relates to data communications 
through the Internet. 

Background Information 

[0002] The traditional workplace is generally thought 
of as a single location to which all employees commuted 
and worked during the day. With the explosion of tech- 
nology, the definition of the workplace is expanding to 
include telecommuters as well as employees that work 
while traveling. In addition, employees may often need 
the ability to login remotely from their home or laptop 
computer systems to their employer's corporate net- 
works for any number of reasons including accessing or 
transferring files or simply checking their electronic mail. 
[0003] Figure 1 shows a computer system 101 re- 
motely connected to a local area network (LAN) 1 31 . As 
shown in Figure 1, computer system 101 is coupled to 
LAN 1 31 through a modem 1 03. Modem 1 03 is connect- 
ed to modem 105 through a connection 127. Modem 
1 05 is connected to a LAN bus 1 07, to which a plurality 
of other network resources are attached. For example, 
Figure 1 shows that computer systems 1 1 3 and 1 1 7 are 
coupled to LAN bus 1 07 through network interfaces 111 
and 115, respectively. 

[0004] A disadvantage with the setup described 
above for remotely coupling computer system 101 to 
corporate LAN 131 through the modems 103 and 105 
is that connection 127 is typically a telephone connec- 
tion through a public switched telephone network. Thus, 
if computer system 101 is located a great physical dis- 
tance away from LAN 131, connection 127 may be a 
long distance telephone call, which could be quite ex- 
pensive if used often or for long periods of time. 
[0005] Figure 1 also shows that in the alternative, 
computer system 101 may be coupled to LAN 131 
through the Internet 119. As shown in Figure 1, compu- 
ter system 101 connects to an Internet service provider 
(ISP) 121 through connection 133. Typically, connection 
1 33 is a local telephone call, which is more cost-effective 
in comparison with connection 1 27 in the event that con- 
nection 127 is a long distance telephone call. Figure 1 
shows that ISP 121 is connected to a gateway system 
109 through a connection 129 through the Internet 119. 
Gateway system 109 is connected to LAN 131 through 
LAN bus 107. 

[0006] There are a variety of different protocols that 
may be used for connection 129 between ISP 121 and 
gateway system 1 09. One such example protocol is the 
Point-to-Point Tunnel Protocol (PPTP). A shortcoming 



of this protocol is that it does not provide complete se- 
curity in connection 129. As is known to those skilled in 
the art, the control channel of a PPTP connection is not 
encrypted. Consequently, it would be relatively easy for 
5 an intruder 125 to intercept the non-protected commu- 
nications in connection 129 between ISP 121 and gate- 
way system 1 09 and conceivably eavesdrop on commu- 
nications, disrupt communications, or possibly even 
masquerade as one of the two parties. 
w [0007] One known protocol providing secured com- 
munications through the Internet 1 1 9 is the Internet Se- 
curity Association and Key Management Protocol 
(ISAKMP)/Oakley protocol combined with Internet Pro- 
tocol Security (IPSec). ISAKMP/Oakley is used for key 
15 management and I PSec is used for transferring encrypt- 
ed data. As is known to those skilled in the art, the 
ISAKMP/Oakley protocol was designed to be used pri- 
marily for providing secured static host to host commu- 
nications through the Internet 119 between networks 
20 that are not shut down often. For example, a pair of net- 
works such as LAN 131 could communicate securely 
through the Internet 119 using the ISAKMP/Oakley pro- 
tocol with IPSec. When designing the ISAKMP/Oakley 
protocol, it was assumed that the secured host to host 
25 (e.g. firewall to firewall) communications through the In- 
ternet 119 between networks would be relatively static. 
That is, the connections between the networks would 
remain active for relatively long periods of time and 
therefore would not be dropped frequently. 
30 [0008] One disadvantage of using the ISAKMP/Oak- 
ley protocol with IPSec in the example illustrated in Fig- 
ure 1 is that computer system 1 01 accesses the Internet 
1 1 9 through modem 1 03. As is known to those skilled in 
the art, it is known that modem connections to the Inter- 
ns net 119 may drop often. For example, if connection 133 
is on a noisy telephone line or if for example connection 
133 includes the call waiting service, connection 133 
could be dropped unexpectedly. As is known to those 
skilled in the art, the ISAKMP/Oakley protocol does not 
40 provide a keepalive feature. Consequently, LAN 131 
would not be aware that computer system 101 was no 
longer reachable until the connection between compu- 
ter system 101 and LAN 131 times out. Generally, 
ISAKMP/Oakley connections time out after attempts to 
45 renegotiate the policy and keys used to secure the com- 
munications link have failed. It is appreciated that the 
attempts to renegotiate the policy and keys to secure 
communications under the ISAKMP/Oakley protocol 
are computationally intensive operations and are there- 
to fore not performed at a high enough frequency to detect 
quickly and reliably that computer system 101 is no long- 
er reachable through Internet 119. 

SUMMARY OF THE INVENTION 

55 

[0009] A method of verifying the reachability of a re- 
mote box from a local box is disclosed. In one embodi- 
ment, the method includes the steps of establishing a 
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protected Internet communications link between the lo- 
cal box and the remote box. A protected keepalive mes- 
sage is transmitted to the remote box from the local box. 
The protected Internet communications link is terminat- 
ed if the remote box fails to transmit to the local box a 
protected acknowledgement message in response to 
the protected keepalive message. Additional features 
and benefits of the present invention will become appar- 
ent from the detailed description, figures and claims set 
forth below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0010] The present invention is illustrated by way of 
example and not limitation in the accompanying figures. 
[0011] Figure 1 is an illustration of a remote computer 
system accessing a LAN through a modem. 
[001 2] Figure 2 is an illustration of a remote computer 
system accessing a LAN through the Internet using a 
modem with secured communications in accordance 
with teachings of one embodiment of the present inven- 
tion. 

[0013] Figure 3 is an illustration showing an example 
of a computer system that may be used in accordance 
with teachings of one embodiment of the present inven- 
tion. 

[0014] Figure 4 is a flow diagram illustrating steps per- 
formed to verify the reachability of a remote computer 
from a local computer in accordance with the teachings 
of one embodiment of the present invention. 

DETAILED DESCRIPTION 

[0015] Methods and apparatuses for verifying the 
reachability of a remote computer from a local computer 
are disclosed. The subject of invention will be described 
with reference to numerous details set forth below, and 
the accompanying drawings will illustrate invention. The 
following description and drawings are illustrative of the 
invention and are not to be construed as limiting the in- 
vention. Numerous specific details are described to pro- 
vide a thorough understanding of invention. However, 
in certain instances, well-known or conventional details 
are not described in order not to unnecessarily obscure 
the present invention. 

[0016] Figure 2 shows a computer system 101 cou- 
pled to a LAN 131 through the Internet 119 in accord- 
ance with the teachings of one embodiment of the 
present invention. In particular, Figure 2 shows a com- 
puter system 101 coupled to the Internet 119 through 
ISP 121 through connection 133 from modem 103. In 
one embodiment, a protected Internet communications 
link is established between ISP 121 and gateway sys- 
tem 109. In the embodiment depicted in Figure 2, the 
protected Internet communications link between ISP 
1 21 and gateway system 1 09 includes the first and sec- 
ond channels 201 and 203, respectively. LAN 131 ac- 
cesses the Internet 119 through gateway system 109. 



In one embodiment, gateway system 109 is coupled to 
LAN bus 107, to which other LAN 131 resources are 
connected including modem 1 05 and computer systems 
113 and 117 through network interfaces 111 and 115, 

5 respectively. 

[0017] It will be appreciated herein that the term "In- 
ternet" refers to a network of networks that use a variety 
of protocols, such as for example the Transmission Con- 
trol Protocol/Internet Protocol (TCP/IP) protocol, and 

10 other protocols including the HTTP for Hypertext 
Markup Language (HTML) documents. The physical 
connections of the Internet 119 and other protocols and 
communication procedures of the Internet 119 are well 
known to those skilled in the art. Access to Internet 119 

15 is typically provided by Internet service providers (ISPs) 
such as ISP 121 and gateway systems, such as gate- 
way system 109. Users on client systems, such as for 
example computer system 101, computer system 113 
and computer system 1 1 7, obtain access to the Internet 

20 11 9 through ISPs such as ISP 121 or gateway systems 
such as gateway system 1 09. Access to the Internet 1 1 9 
allows users of client computer systems to exchange in- 
formation, receive and send electronic mail, view elec- 
tronic documents, etc.. 

25 [0018] It is noted that while the embodiment illustrated 
in Figure 2 depicts that computer system 1 01 is coupled 
to the Internet 119 through a "modem" 103, it is appre- 
ciated that the interface of computer system 101 to In- 
ternet 119 through modem 103 may be an analog mo- 

30 dem, an Integrated Services Digital Network (ISDN) mo- 
dem, cable modem, satellite transmission interface, 
Digital Subscriber Line (DSL) modem, or other interfac- 
es for coupling a computer system or box to other com- 
puter systems or boxes. 

35 [0019] Computer systems 113 and 117 are shown in 
the embodiment illustrated in Figure 2 to be coupled to 
LAN bus 107 through network interfaces 111 and 115, 
which may be an Ethernet network interfaces or other 
known network interfaces. In one embodiment, LAN bus 

40 1 07 is coupled to gateway system 1 09, which may pro- 
vide firewall and other Internet related services for LAN 
131. In one embodiment, gateway system 109 may be 
a conventional server computer system, or another type 
of box including for example an Extranet switch that pro- 

45 vides Internet 1 1 9 access for LAN 131. 

[0020] Figure 3 shows one embodiment of a conven- 
tional computer system 301 that may be included in 
computer systems 101, 113 and 1 1 7 or gateway system 
109 of Figure 2. It will also be appreciated that a com- 

50 puter system 301 may be used to perform many of the 
functions of Internet service provider, such as for exam- 
ple ISP 121 or the functions of remote and local boxes 
in accordance with the teachings of the present inven- 
tion. The computer system 301 interfaces to external 

55 systems or boxes through the modem or network inter- 
face 319. 

[0021] Although modems and network interfaces 
have been separately illustrated in Figure 2, such as for 
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example modems 103 and 105 and network interfaces 
111 and 115, it will be appreciated that the modem or 
network interface 319 may be considered in some in- 
stances to be part of computer system 301 . This modem 
or network interface 31 9 may be an analog modem, IS- 
DN modem, cable modern, DSL modem, token ring in- 
terface, Ethernet interface, satellite transmission inter- 
face, or other interfaces for coupling a computer system 
or box to other computer systems or boxes. As also 
shown in Figure 3, a carrier wave signal 321 is received/ 
transmitted by modem or network interface 321 for com- 
munications with computer system 301 . 
[0022] In the embodiment illustrated in Figure 3, com- 
puter system 301 includes a processor 303, which may 
be a conventional microprocessor such as for example 
an Intel x86 or Pentium family microprocessor, a Mo- 
torola 68K or PowerPC family microprocessor, or the 
like. Memory 305 is coupled to processor 303 by a bus 
307. Memory 305 may be dynamic random access 
memory (DRAM) and may include static random access 
memory (SRAM). Bus 307 couples processor 303 to 
memory 305 and also to mass memory 313 and to dis- 
play controller 309 and the I/O (input/output) controller 
315. 

[0023] Mass memory 313 is often a magnetic hard 
disk, an optical disk, or another form of storage for large 
amounts of data. Some of this data is may be written by 
a direct memory access process into memory 305 dur- 
ing execution of software and computer system 301 . It 
is appreciated that software may also be transmitted or 
received via modem or network interface 319. For pur- 
poses of this specification, the term "computer readable 
medium" shall be taken to include any medium that is 
capable of storing or encoding a sequence of instruc- 
tions for execution by a processor and causes the proc- 
essor to perform the methodologies of the present in- 
vention. The term "computer readable medium" shall be 
taken to include, but not be limited to solid-state mem- 
ories, optical and magnetic disks, carrier wave signals, 
or the like. 

[0024] It will be appreciated that computer system 301 
is merely one example of many possible computer sys- 
tems that have different architectures. For example, 
WINTEL systems, systems that include Intel microproc- 
essors running the Microsoft Windows operating sys- 
tem, often have multiple buses, one of which may be 
considered a peripheral bus. Networked computers may 
also be considered to be a computer system that may 
be used with the present invention. Network computers 
may not include a hard disk or other mass memory 313, 
and the executable programs are loaded from a network 
connection into memory 305 for execution by processor 
303. A typical computer system will usually include at 
least processor 303, memory 305 and a bus 307 for cou- 
pling memory 305 to processor 303. 
[0025] It will also be appreciated that computer sys- 
tem 301 is controlled by operating system software that 
includes a file management system, such as a disk op- 



erating system, which is part of the operating system 
software. One example of an operating system software 
with its associated file management system software is 
the operating system known as Windows from Microsoft 

5 Corporation of Redmond Washington, and its associat- 
ed file management system, including Windows Explor- 
er. The file management system is typically stored in the 
mass memory 313 and causes processor 303 to exe- 
cute the various steps required by the operating system 

10 to input and output data and to access data in memory, 
including accessing files in mass memory 313. 
[0026] Referring back to the embodiment depicted in 
Figure 2, a user on computer system 1 01 is able to ac- 
cess LAN 131 securely and remotely through a protect- 

15 ed communications linkthrough Internet 1 1 9. Converse- 
ly, users on LAN 131 are able to access computer sys- 
tem 101 securely and remotely through the protected 
Internet communications link. In one embodiment, the 
protected communications link through Internet 1 1 9 be- 

20 tween computer system 101 and gateway system 109 
employs the Internet Security Association and Key Man- 
agement Protocol (ISAKM P)/Oakley protocol to secure 
communications. As is known to those skilled in the art, 
ISAKMP/Oakley is the key management protocol de- 

25 signed by the Internet Engineering Task Force (IETF) 
Internet Protocol Security (IPSec) working group. 
[0027] As is known to those skilled in the art, ISAKM PI 
Oakley provides a framework for authentication, secu- 
rity association negotiation and key management for the 

30 protected. Internet communications link between com- 
puter system 101 and gateway system 109. Specifically, 
ISAKM P provides a framework for authentication and 
key exchange, but does not define them. Oakley de- 
scribes a series of key exchanges and details the serv- 
es ices provided by each. In one embodiment, the Oakley 
protocol defines a generic key exchange protocol em- 
ploying the well-known and complex Diffie-Hellmen key 
exchange algorithm. As such, the periodic renegotiation 
of the keys used to secure the protected Internet com- 

40 munications link between computer system 101 and 
gateway system 1 09 is a computationally intense oper- 
ation. 

[0028] Information describing the ISAKMP/Oakley 
protocol may be found in the following Internet Draft 

45 working documents: Maughan et al., 'Internet Security 
Association and Key Management Protocol (ISAKM P), 
ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp- 
10.txt; Orman, "The OAKLEY Key Determination Proto- 
col," ftF.ietf.org/internet-drafts/draft-ietf-ipsec-oakley- 

50 02.txt; and Harkins & Carrel, The Internet Key Ex- 
change (IKE)," ftp.ietf.org/internet-drafts/draft-ietf- 
ipsec-isakmp-oakley-08.txt. These documents are in- 
corporated herein by reference. 

[0029] In the embodiment depicted in Figure 2, the 
55 protected communications link through the Internet 1 1 9 
includes a first channel 201 and a second channel 203 
between ISP 121 and gateway system 109. As a result, 
two protected links 213 and 215 are formed between 
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computer systems 1 01 and gateway system 1 09. In the 
embodiment illustrated in Figure 2, protected link 21 3 is 
formed between computer system 101 through modem 
103, through connection 133 to ISP 121 , through chan- 
nel 203 to gateway system 1 09. Similarly, protected link 
215 is formed between computer system 101 through 
modem 103, through connection 133 to ISP 121, 
through channel 203 to gateway system 109. 
[0030] In one embodiment, protected link 215 and 
channel 201 carry control traffic used for, among other 
things, negotiating and renegotiating the policy/key(s) 
21 1 used for securing channels 201 and 203 of the pro- 
tected Internet communications link. In one embodi- 
ment, the ISAKMP/Oakley traffic including policy/key(s) 
211 is carried in channel 201. In one embodiment, all 
traffic in channel 201 is encrypted and therefore protect- 
ed. In one embodiment, channel 203 is also a protected 
channel and protected link 213 with channel 203 carry 
protected data 205 using IPSec between ISP 121 gate- 
way system 1 09. In one embodiment, channel 203 car- 
ries IPSec tunnel traffic. 

[0031] In accordance with one embodiment of the 
present invention, when the protected Internet commu- 
nications link is established between computer system 
1 01 and gateway system 1 09 of LAN 1 31 , the policy/key 
(s) 211 used for protecting channels 201 and 203 are 
negotiated under the ISAKMP/Oakley protocol. In one 
embodiment, the established secure and authenticated 
channel through which computer system 1 01 and gate- 
way system 109 communicate through Internet 119 is 
called a security association under the ISAKMP/Oakley 
protocol. After the secured Internet communications link 
has been established, computer system 101 and LAN 
131 are able to communicate securely. Since channels 
201 and 203 are secured, it is extremely difficult for an 
intruder 1 25 to eavesdrop, interfere with or disrupt com- 
munications between computer system 101 and LAN 
131. 

[0032] In one embodiment, the policy/key(s) 21 1 used 
under the ISAKMP/Oakley protocol are renegotiated pe- 
riodically to maintain the security of the protected Inter- 
net communications link between computer system 1 01 
and gateway system 109. In one embodiment, the pol- 
icy/key^) 211 are renegotiated after a predetermined 
amount of time has elapsed since the previous time the 
policy/key(s) 211 have been negotiated. In another em- 
bodiment, the policy/key(s) 211 are renegotiated after a 
predetermined amount of data has been transferred 
through the protected Internet communications link 
since the last time the policy/key(s) 211 have been ne- 
gotiated. 

[0033] As mentioned earlier, since the process to es- 
tablish the policy/key(s) 21 1 is a computationally intense 
procedure, there is a practical limit on how often the re- 
negotiation process can be performed. As is appreciat- 
ed to those skilled in the art, the frequency in which the 
renegotiation process under ISAKMP/Oakley typically 
occurs is on the order of only every several times per 



day. Otherwise, computer system 101 and/or gateway 
system 109 would be unduly burdened with having to 
recompute the policy/key(s) 211 under the Diffie-Hell- 
men key exchange algorithm. 

5 In the event that a remote computer or box fails to re- 
spond to a re-key request under the ISAKMP/Oakley 
protocol, it is assumed that the remote computer box is 
no longer reachable and the protected Internet commu- 
nications link and associated security association under 

10 the ISAKMP/Oakley protocol is torn down. 

[0034] As described above, computer system 1 01 ac- 
cesses Internet 119 through a modem connection from 
modem 103. Consequently, there is a reasonable pos- 
sibility that the connection 133 between modem 103 and 

15 ISP 1 21 may drop at a frequency higher than that which 
could be quickly and practically detected by gateway 
system 1 09 by simply relying on a timeout exception oc- 
curring after a ISAKMP/Oakley re-key or renegotiation 
request. Indeed, as described above, the renegotiation 

20 process is typically performed only several times per 
day. Unfortunately, the ISAKMP/Oakley protocol was 
originally designed primarily to secure Internet commu- 
nications between systems that do not go down regu- 
larly. The ISAKMP/Oakley protocol was not originally 

25 designed for users logging into networks using unrelia- 
ble modem connections. Thus, if a connection 133 is 
unexpectedly dropped for any reason and the user of 
computer system 101 attempts to re-access LAN 131 
through a secured ISAKMP/Oakley connection through 

30 Internet 119, there is a possibility that the user may be 
unable to re-login to LAN 131 because gateway system 
109 is unaware that the previous connection 133 be- 
tween modem 103 and ISP 121 has been dropped. 
[0035] In particular, under ISAKMP/Oakley, gateway 

35 system 1 09 will not have torn down the security associ- 
ation of the previous protected Internet communications 
link. Consequently, if the user of computer 1 01 is entitled 
to only one secured link to LAN 131 and under ISAKMP/ 
Oakley, the user will be unable to login until the previous 

40 secured association is torn down. However, under 
ISAKM P/Oakley, the security association will not be torn 
down until the above described timeout exception oc- 
curs after the renegotiation request, which in some in- 
stances may occur only several times a day. 

45 [0036] In another situation, it is appreciated that a 
router or other hardware device contained in Internet 
119 through which communications between computer 
system 101 and LAN 131 are carried may also fail. In 
this example, connection 133 between modem 103 and 

50 ISP 121 may not have been unexpectedly dropped, but 
nevertheless, computer system 101 is not reachable 
from LAN 131 and vice versa. It is appreciated that in 
this situation, gateway system 109 may also be unaware 
that computer system 101 is not reachable for many 

55 hours until the above described timeout exception oc- 
curs after the renegotiation request. 
[0037] In order to address the above described prob- 
lem, one embodiment of the present invention transmits 
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a protected keepalive message 209 to the remote com- 
puter system or box from the local computer system or 
box. In one embodiment, the local box may be computer 
system 1 01 and the remote box may be gateway system 
1 09. In another embodiment, the local box may be gate- 
way system 109 and the remote box may be computer 
system 1 01 . indeed, the present invention is applicable 
to any combination of local and remote boxes between 
which there are secured communications through the 
Internet 119. 

[0038] In one embodiment, the protected keepalive 
message is a message to which it is mandatory to send 
a protected acknowledgement signal. In an embodiment 
implying the ISAKMP/Oakley protocol, the keepalive 
message 209 is a protected ISAKMP/Oakley message 
sent from the local box to the remote box. In one em- 
bodiment, the protected ISAKMP/Oakley message is a 
message to which the remote box must reply with a pro- 
tected acknowledgement message 207. In one embod- 
iment, the protected keepalive message 209 and the 
protected acknowledgement message 207 are transmit- 
ted through protected link 21 5 and the first channel 201 
between ISP 121 and gateway 1 09. Since the protected 
keepalive message 209 and the protected acknowl- 
edgement message 207 are secured under the 
ISAKMP/Oakley protocol, it is appreciated that it is ex- 
tremely difficult for an intruder 125 to intercept or ma- 
nipulate protected keepalive message 209 and protect- 
ed acknowledgement 207 in accordance with teachings 
of the present invention. 

[0039] In one embodiment, since the ISAKMP/Oakley 
protocol was not implemented with a keepalive mes- 
sage, another ISAKMP/Oakley non-keepalive com- 
mand is used as a keepalive message 209. In one em- 
bodiment, an ISAKMP/Oakley quick mode message in- 
cluding an invalid proposal and transform is used as a 
keepalive message 209 in accordance with the teach- 
ings of the present invention. In one embodiment, this 
quick mode message is transmitted by the local box to 
the remote box after the communications link has been 
idle for a period of time. In one embodiment, this keep- 
alive message 209 is transmitted by the local box after, 
for example, one minute has passed when no traffic has 
been sent to or received from the remote box. Under the 
ISAKMP/Oakley protocol, the remote box must reply 
back to the local box by sending a protected acknowl- 
edgement 207 back to the local box. 
[0040] In the event that the local box does not receive 
the protected acknowledgement message 207 back 
from the remote box after having transmitted the pro- 
tected keepalive message 209, is assumed that the re- 
mote box is no longer reachable. As discussed above, 
this may occur if the modem connection between mo- 
dem 103 and ISP 121 is dropped or if for example a rout- 
er or other piece of hardware in Internet 119 providing 
the protected Internet communications link fails. As a 
result, the local box can terminate the protected Internet 
communications link between computer system 101 



and gateway system 1 09 in accordance with the teach- 
ings of the present invention. In one embodiment, the 
local box tears down the associated security association 
under the ISAKMP/Oakley protocol. 

5 [0041] Figure 4 is a flow diagram illustrating steps per- 
formed in accordance with the teachings of one embod- 
iment of the present invention. It is appreciated that the 
steps performed in accordance with the teachings of the 
present invention may be implemented as software, 

10 firmware, hardware, etc., in the local and remote boxes. 
Processing step 403 shows that secured communica- 
tions are established between a local box and a remote 
box through first and second channels through the In- 
ternet. Processing step 405, shows that the policy/key 

15 (s) between the local box and the remote box are nego- 
tiated or renegotiated to protect the secured first and 
second channels. 

[0042] Processing decision step 407 shows that it is 
next determined whether there have been any commu- 

20 nications between the local box and the remote box in 
the past N minutes. Stated differently, it is determined 
whether the secured communications between the local 
box and the remote box have been idle in the past N 
minutes. Is appreciated that N may be chosen to be a 

25 value that would on the one hand enable a dropped con- 
nection between the remote box and local box to be de- 
tected in a relatively short period of time, but on the other 
hand would not unduly burden the secured communica- 
tions link between the local and remote boxes with keep- 

30 alive traffic. 

[0043] If there has been communications traffic be- 
tween the local box and remote box in the past N min- 
utes, then processing decision step 409 shows that it is 
next determined whether X Kbytes have been trans- 

35 ferred between the remote box and local box or if Y 
hours have lapsed since the most recent time that the 
policy/key(s) have been negotiated. It is appreciated 
that X or Y are chosen to be values that enable the 
ISAKMP/Oakley policy/key(s) to be changed at ade- 

40 quate intervals for security reasons while at the same 
time X or Y are chosen to be values that t would not 
excessively burden the remote and/or local boxes with 
the computationally intensive processing required to re- 
negotiate the policy/key(s). 

45 [0044] If the conditions of processing decision step 
409 are met, then processing loops back to processing 
step 405 where the policy/key(s) are renegotiated to 
protect the secured communications link. If the condi- 
tions of processing decision step 409 are not met, then 

50 processing loops back to processing decision step 407 
where it is again determined whether there have been 
any communications between the remote and local box- 
es within the past N minutes. 

[0045] In the event that there have not been any com- 
55 munications between the local and remote boxes in the 
past N minutes, then processing from processing deci- 
sion step 407 proceeds to processing step 411. 
Processing step 411 shows that a protected keepalive 
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message is sent from the local box to the remote box 
through the first channel. As discussed above, the keep- 
alive message is a message to which a protected ac- 
knowledgement must be sent. Accordingly, processing 
decision step 413 shows that it is next determined 
whether a protected acknowledgement to the keepalive 
message has been received from the remote box. If so, 
then processing loops back to processing decision step 
407. In this case, it is assumed that the remote box is 
reachable. However, if the protected acknowledgement 
is not received, then processing proceeds to processing 
step 415 where it is shown that the secured communi- 
cations between the local and remote boxes are discon- 
tinued. Indeed, if the protected acknowledgement is not 
received in processing decision step 413, it is assumed 
that the remote box is no longer reachable from the local 
box. 

[0046] The foregoing discussion has provided numer- 
ous examples of the present invention. It will be appre- 
ciated that various modifications and changes may be 
made thereto without departing from a broader spirit and 
scope of the present invention as set forth in the append- 
ed claims. 



Claims 

1. A method of verifying reachability of a remote box 
from a local box, the method comprising: 

establishing a protected Internet communica- 
tions link between the local box and the remote 
box; 

transmitting a protected keepalive message to 
the remote box from the local box; and 
terminating the protected Internet communica- 
tions link if the remote box fails to transmit to 
the local box a protected acknowledgement 
message in response to the protected keep- 
alive message. 

2. A method of maintaining a protected Internet com- 
munications link between a local box and a remote 
box, the method comprising: 

renegotiating periodically a policy and a key be- 
tween the local box and the remote box to se- 
cure the protected Internet communications 
link; 

transmitting a protected keepalive message to 
the remote box from the local box; and 
terminating the protected Internet communica- 
tions link if the remote box fails to transmit to 
the local box a protected acknowledgement 
message in response to the protected keep- 
alive message. 

3. A computer readable medium having sequences of 



instructions stored therein, which when executed 
cause a processor to perform a method comprising: 

establishing a protected Internet communica- 
5 tions link between a local box and a remote box; 

transmitting a protected keepalive message 
from the local box to the remote box; and 
terminating the protected Internet communica- 
tions link if the remote box fails to transmit to 
10 the local box a protected acknowledgement 

message in response to the protected keep- 
alive message. 

4. The method of claim 1 or 2 or the medium of claim 
15 3, wherein transmitting the protected keepalive 
message to the remote box from the local box is 
performed after the protected Internet communica- 
tions link has been idle. 

20 5. The method of claim 1 or 2 or the medium of claim 
3, wherein establishing the protected Internet com- 
munications link between the local box and the re- 
mote box includes: 

25 establishing a protected first channel through 

the Internet between the local box and the re- 
mote box through which control information is 
transferred; and 

establishing a protected second channel 
30 through the Internet between the local box and 

the remote box through which data information 
is transferred. 

6. The method or medium of claim 5 wherein the pro- 
35 tected keepalive message and the protected ac- 
knowledgement message are transmitted through 
the protected first channel between the local and 
remote boxes. 

40 7. The method of claim 1 or 2 or the medium of claim 
3, wherein it is mandatory that the remote box trans- 
mit the protected acknowledgement message to the 
local box in response to receiving the protected 
keepalive message and wherein establishing the 

45 method of claim 1 wherein establishing the protect- 
ed Internet communications link between the local 
box and the remote box, includes negotiating a pol- 
icy and a key between the local box and the remote 
box to secure the protected Internet communica- 

50 tions link. 

8. The method of claim 1 or the medium of claim 3, 
wherein it is mandatory that the remote box transmit 
the protected acknowledgement message to the lo- 
ss cal box in response to receiving the protected keep- 
alive message and wherein establishing the pro- 
tected Internet communications link between the lo- 
cal box and the remote box, includes negotiating a 
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policy and a key between the local box and the re- 
mote box to secure the protected Internet commu- 
nications link. 

9. The method or medium of claim 8 further comprising 5 
renegotiating the policy and the key between the lo- 
cal box and the remote box periodically to secure 
the protected Internet communications link. 

10. The method or medium of claim 9 wherein renego- 10 
tiating the policy and the key between the local box 
and the remote box periodically to secure the pro- 
tected Internet communications link, is performed 
after a predetermined period of time has elapsed. 

15 

11. The method or medium of claim 9 wherein renego- 
tiating the policy and the key between the local box 
and the remote box periodically to secure the pro- 
tected Internet communications link, is performed 
after a predetermined amount of information has 20 
been transferred between the local box and the re- 
mote box. 

12. The method of claim 1 or 2 or the medium of claim 

3, wherein establishing the protected Internet com- 25 
munications link between the local box and the re- 
mote box, is performed using the Internet Security 
Association and Key Management Protocol 
(ISAKMP)/Oakley protocol. 

30 

13. The method or medium of claim 12 wherein the pro- 
tected keepalive message is a protected ISAKMP/ 
Oakley message to which the protected acknowl- 
edgement message must be transmitted from the 
remote box in response. 35 

14. The method or medium of claim 13 wherein the pro- 
tected ISAKMP/Oakley message is a protected 
ISAKMP/Oakley quick mode message with an 
invalid proposal and transform. 40 

15. The method of claim 1 or 2 or the medium of claim 
3, wherein the protected Internet communications 
link between the local box and the remote box in- 
cludes an ISAKMP/Oakley security association. 45 

16. The method or medium of claim 15 wherein termi- 
nating the protected Internet communications link, 
includes tearing down the ISAKMP/Oakley security 
association. 50 

17. The method or medium of claim 9 wherein transmit- 
ting the protected keepalive message to the remote 
box from the local box, is performed separately from 
renegotiating the policy and the key between the lo- 55 
cal box and the remote box periodically to secure 

the protected Internet communications link. 
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